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Abstract 

The Spaceport Processing Systems Branch at NASA 
Kennedy Space Center has developed and deployed a soft- 
ware agent to monitor the Space Shuttle's ground process- 
ing telemetry stream , . The application, the Launch Commit 
Criteria Monitoring Agent, increases situational aware- 
ness for system and hardware engineers during Shuttle 
launch countdown. The agent provides autonomous mon- 
itoring of the telemetry stream, automatically alerts sys- 
tem engineers when predefined criteria have been met, 
identifies limit warnings and violations of launch com- 
mit criteria, aids Shuttle engineers through troubleshooting 
procedures, and provides additional insight to verify ap- 
propriate troubleshooting of problems by contractors. 
The agent has successfully detected launch commit crite- 
ria warnings and violatons on a simulated playback data 
stream. Efficiency and safety are improved through in- 
creased automation. 


1. Introduction 

This paper describes a software agent 1 that is used for 
processing Space Shuttle telemetry data and notifying sys- 
tem engineers of warnings and violations. After describing 
the problem and objectives, the environment, interfaces, ap- 
plication description, and extension of the agent for future 
uses will be presented. 

1.1. Background 

NASA Kennedy Space Center (KSC) is responsi- 
ble for pre-launch ground checkout of the Space Shuttle. 


1 A demonstration of this system will be available to be shown at the 
conference. 
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Figure 1. Ground Control and Monitoring at 
NASA KSC 


The Launch Processing System (LPS) at KSC provides fa- 
cilities for NASA Shuttle system engineers, contractors, 
and test conductors to command, control, and moni- 
tor space vehicle systems from the start of Shuttle interface 
testing through various phases including terminal count- 
down, launch, abort, safing, and scrub turnaround. 

LPS continually monitors the Shuttle and its ground 
equipment including environmental controls and hardware 
that loads propellants. Consoles with vehicle responsibili- 
ties communicate information directly to and from the Shut- 
tle computer systems. Consoles with ground support equip- 
ment responsibility communicate information to and from 
the hardware interface modules which are connected to the 
numerous ground support systems. See Figure 1. Each mod- 
ule is capable of interfacing to approximately 240 sensors 
or controls. Overall, some 50,000 temperatures, pressures, 
flow rates, liquid levels, turbine speeds, voltages, currents, 
valve positions, switch positions, and many other parame- 
ters must be controlled and monitored. 

For over 25 years, engineers have used LPS to verify 
Space Shuttle flight readiness and to control launch count- 
down. LPS has performed superbly well. Recently, much 
of the LPS hardware was upgraded assuring its continu- 
ance for many more years. However, the system architec- 
ture was not changed and software remains basically the 
same. As a result, the level of situational awareness has not 
increased proportionally to what would otherwise be possi- 






ble with more modem software technologies. 

After the Shuttle Columbia disaster on February 1, 2003, 
the Columbia Accident Investigation Board [14] proposed 
recommendations to improve safety from both an organi- 
zational and technical perspective. The Board indicated the 
need to “[adopt] and maintain a Shuttle flight schedule that 
is consistent with available resources ” Also, both manage- 
ment and engineering support staff must maintain an aware- 
ness of anomalies and those must not be lost “as engineer- 
ing risk analyses [move] through the process ” Given two 
tragic losses of a crew and Shuttle, today NASA engineers 
have an even greater pressure to be more vigilant in identi- 
fying problems. Anomalies must be detected and reported 
to prevent problems with Shuttle subsystems, countdown, 
and launch. The aging LPS hardware has limited resources 
and precludes the level of automation and notification war- 
ranted by this domain. 

1.2. Problem Description 

During launch countdown, NASA Shuttle engineers are 
required to monitor shuttle data for violations of the launch 
commit criteria (LCC) and to verify that the contractors 
troubleshoot problems correctly. When a violation is rec- 
ognized by the system engineers it is reported to the NASA 
Test Director. The problem report, or call, includes a de- 
scription of the problem, the criticality, whether a hold is 
requested, and whether a preplanned troubleshooting pro- 
cedure exists. Many systems have a large number of mea- 
surements with associated LCC limits and a large num- 
ber of LCC requirements. Table 1 shows four representa- 
tive Shuttle subsystems and their corresponding number of 
LCCs and measurements. As illustrated, hundreds of mea- 
surements must be monitored just for this small set of sub- 
systems. 

The Shuttle is composed of many subsystems (e.g. Main 
Propulsion, Hydraulics). Each of those subsystems has a 
team of engineers responsible for troubleshooting problems 
for that respective system during a launch countdown. Each 
team has its own tools for identifying LCC violations. Many 
of these tools use the LPS software and simply change the 
color of the displayed data and/or present a text message 
to the user or set off an audible alarm. Troubleshooting 
may require other displays such as plots and troubleshoot- 
ing flowcharts. Valuable time is spent locating these pro- 
cedures and locating the data that supports them. Table 2 
shows some sample limits for the Power Reactant Supply 
and Distribution (PRSD) subsystem. In this case minimum 
and maximum limits are specified for pressure measure- 
ments associated with two hydrogen tanks. Limits can be 
much more complex, involving limits calculated from other 
measurements and limits that apply only to specific times 
during the countdown. 


Given the possible complexity of limits, the large num- 
ber of limits, and the need to get supporting data quickly 
Shuttle engineers needed an advisory tool to provide more 
insight and situational awareness during launch countdown. 
In the latter half of 2003, a software tool was proposed to 
provide additional insight during Shuttle launch countdown 
and increase the level of situational awareness. The tool, 
called the Launch Commit Criteria Monitoring Agent (LC- 
CMA), complements LPS and is capable of autonomously 
and continuously monitoring Shuttle telemetry data. LC- 
CMA automatically alerts NASA Shuttle engineers when 
predefined criteria (e.g. limit violations, warnings) have 
been met and guides the engineers through troubleshoot- 
ing procedures. 

1.3. Objectives 

LCCMA acts as a software agent for the NASA engineer. 
For this discussion, an agent is defined as rule-based, au- 
tonomous software that reacts to its environment and com- 
municates results to a human, a NASA engineer in this 
usage. Agents have been extensively researched [22, 19]. 
Agents standards [9] and frameworks [1, 15] have also been 
developed. 

The primary objectives for LCCMA include: 

• Monitor Space Shuttle telemetry ground data. 

• Allow a NASA engineer to specify rules to be applied 
to Space Shuttle telemetry ground data. 

• Display a visual indication of violated LCCs. 

• Display a text message of the LCC violation call. 

• Display troubleshooting steps from preplanned proce- 
dures. 

LCCMA does not send any commands and is used for 
advisory purposes only. A future release of LCCMA will 
include an interactive troubleshooting display that reads the 
data stream and accepts user inputs to direct diagnostic trou- 
bleshooting. 

2. Environment and Interfaces 
2.1. Shuttle Data Stream 

Data processed by LPS is distributed on a local area net- 
work. As shown in Figure 1, the distributed data is known as 
the Shuttle Data Stream (SDS) [16] and contains real-time 
vehicle and ground processing data. Thousands of teleme- 
try measurements are published in the SDS and are used 
by monitor-only applications such as LCCMA. The SDS 
contains multiple types and subtypes of measurements in- 
cluding discretes (i.e. boolean measurements), analogs (i.e. 
floating point measurements), and digital patterns (i.e. inte- 
ger measurements). 



Subsystem 

Number of LCCs 

Number of Measurements 

APU/HYD 

50 

252 

ECLSS 

29 

136 

PRSD 

15 

113 

QMS 

18 

434 


Table 1. Number of Measurements for Various Shuttle Subsystems 


Measurement Id 

Description 

Min 

Max 

Units 

V45P2110A 

Tank 1 Heater Control Pressure 

196 

298 

psia 

V45P2100A 

Tank 1 Pressure 

192 

294 

psia 


Table 2. Example LCC Requirements for PRSD H 2 Tank 1 


2.2. LCCMA Context Diagram 

Figure 2 shows the context diagram for LCCMA. The 
agent process, represented in the middle circle, commu- 
nicates with various sources and data stores. A measure- 
ment database is used to decode the SDS into usable mea- 
surements. The SDS source broadcasts measurements as 
data packets over local area networks. LCCMA monitors 
this stream for measurement violations and warnings spec- 
ified by the Shuttle engineers. The Troubleshooting Proce- 
dures source represents html or pdf files containing the trou- 
bleshooting steps, often in flowchart form at. LCCMA sends 
limit violations to the NASA Engineer via the Status Board 
Display. The Rules data store represents the Jess scripts and 
knowledge base that defines the rules for the limit viola- 
tions. 

3. Application Description 

3.1. Languages and AI Tools Used in Application 

The Java Expert System Shell (Jess) [12] was selected as 
the agent’s rule engine. Jess was developed and supported 
by another government agency, Sandia National Labs. As 
such, our development team and customer have full usage 
of the tool via government licensing without any fees. This 
includes access to all the Jess source code. 

Jess’ forward chaining reasoning system was modeled 
after production systems such as OPS5 [3] amd CLIPS [23]. 
It contains highly efficient and sophisticated pattern match- 
ing based on the Rete algorithm [11]. This enables its in- 
ference engine to process many rules and data rapidly. The 
engine repeatedly processes through a match-select-act cy- 
cle. As a production system, its consequents can be actions. 
A conflict resolution strategy determines the precedence of 
rule firings. 


Jess’ predicate logic lends itself to capturing and spec- 
ifying the heuristics and engineering rules of this space- 
port domain. The declarative paradigm of this rule-based 
agent application also makes it highly modular and scal- 
able to span multiple subsystems of the Shuttle. Jess also 
includes a fourth generation scripting language and interac- 
tive command line which are very conducive for prototyp- 
ing and testing. 

Jess is written entirely in Java and has access to the 
full Java application programming interface from the script- 
ing language. It provides standard control flow constructs 
and supports variables, strings, objects, and function calls. 
Jess automatically converts between its own types and Java 
types insulating the developer from manually performing 
the conversions. Its use as a Java library made Jess’ selec- 
tion more appealing since Java supports multiple platforms 
with its “write once, run anywhere” paradigm. Beyond that, 
the need for NESTA to support web enabled clients also 
made Java a natural fit given its origins and strong support 
for developing Internet based applications. 

3.2. Design 

Java classes were developed to parse and decode the data 
stream and represent measurements as facts in Jess’ work- 
ing memory. To interface Jess’ rule engine with the SDS, 
each data measurement is modeled and implemented as a 
Java bean [21]. Java beans provide a component architec- 
ture to enable easier integration of applications. A property 
change notification mechanism is supported that allows one 
object to become a registered listener of another object. The 
listener object will then automatically receive changes from 
the source object. This is also known as a publish-subscribe 
or observer pattern [13]. Within Jess, each Java bean corre- 
sponds to what is known as a shadow fact. A Jess shadow 
fact is a mirror image of a Java bean, such as a pressure 
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Figure 2. LCCMA Context Diagram 


measurement, within Jess’ working memory. All shadow 
facts are registered listeners of their Java bean counterparts. 
Thus, whenever a measurement changes in the data stream, 
a property change event is automatically generated for the 
given measurement and its sibling shadow fact is updated in 
Jess’ working memory. Figure 3 illustrates this path. 

After a shadow fact is updated, the Jess pattern matcher 
will determine if the premises of any rules match the new 
or modified facts. Rules are compared to working mem- 
ory to identify premises that are matched by the data in 
working memory. For LCCMA, this data represents mea- 
surements from the SDS and rules represent data monitor- 
ing criteria submitted by NASA Shuttle system engineers. 
Rules with matching premises are activated and placed onto 
an agenda. Next, the agenda is ordered according to Jess’ 
default conflict resolution strategy. The highest priority rule 
is then fired and executed. This match-select-act cycle re- 
peats until no more rules are available to fire. An action han- 
dler class was developed and is used to build and send the 
notification message to the Shuttle engineer whenever a rule 
fires. 

3.3. Graphical User Interface 

A graphical user interface currently exists for LCCMA 
called the Status Board Display. It is being upgraded and 
Figure 4 shows a storyboard representative of that future in- 
terface. The Status Board Display shows the health of the 
network connection, data stream status, countdown time, 
and other relevant information. 

When LCC limits are violated, the LCC call is displayed 


in the text box. The user reads the text and, if there is an as- 
sociated troubleshooting file, clicks on the file button next to 
the text. This brings up a Troubleshooting Display for that 
particular LCC and limit. The LCC text remains bold un- 
til the Acknowledge button is pushed. Message text can be 
displayed with one of three icons representing a violation, 
warning, or informational cue. 

The text messages can be read over the Operational Inter- 
communication System as LCC calls during the countdown. 
Calls will change based on what limit is violated (e.g. warn- 
ing, LCC, high/low limit), the time criticality of the call, and 
LCC effectivity. The application aids the NASA engineer in 
making a Go/No-Go decision. 


3.4. Execution 


At startup, LCCMA connects to a single data stream 
based on user input and reads a rules file containing LCC 
violation and warning limits. Table 3 shows the conditions 
and actions associated with an LCC warning and violation 
for the hydrogen (H 2 ) tank 1 from Table 2. For example, if 
either of the H 2 tank 1 pressures are above the upper limit, 
the agent should notify the NASA engineer by displaying 
the violation in red font and direct the engineer to the corre- 
sponding troubleshooting file (i.e. PRSD06Hi.pdf) for that 
violation. The troubleshooting file shows the steps neces- 
sary to be taken by the engineer when the specified limits of 
a given subsystem are violated. 








Figure 3. Sequence Diagram Illustrating Update to Jess Working Memory from Shuttle Data Stream 
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Figure 4. LCCMA Status Board Display 


Condition 

Description 

Message 

Action 

(V45P21 10A > 270 
OR V45P2100A > 270) AND 
V45P21 10A <= 298 AND 
V45P2100A <= 294 

H 2 Tank 1 Pressure 
Warning High 

Heater Control Pressure Reading 
[V45P21 10A], 

Tank Pressure Reading 
[V45P2100A] 

Display [Description], 
[Message] in Yellow 

(V45P2110A >298 OR 
V45P2100A > 294) 

H 2 Tank 1 Pressure 
Violation High 

Heater Control Pressure Reading 
[V45P2U0A], 

Tank Pressure Reading 
[V45P2100A] 

Display [Description], 
[Message] in Red. 
Open file 
PRSD06Hi.pdf 


Table 3. Example LCC Conditions and Actions for PRSD H 2 Tank 1 


3.5. Deployment 

LCCMA was delivered to the customer and has suc- 
cessfully detected LCC warnings and violations on an SDS 
recorded playback. It has not been used during an actual 
launch countdown yet since NASA has not returned to flight 
subsequent to the Columbia disaster. However, LCCMA’s 
potential was already recognized by other projects at NASA 
KSC and it is in the process of being integrated into a larger 
monitoring application. For that one, hundreds of customers 
will use LCCMA to enter not just LCC monitoring criteria, 
but many types of simple and complex measurement con- 
straints. 

3.6. Knowledge Representation 

This is an actual LCCMA rule written in the Jess script- 
ing language: 

(def rule orbiter-cabin-o2-pressure-anoro*ly-rule 

"ECL-06 Emergency Condition Yellow Orbiter Cabin 02 Pressure Anomaly* 

?activat ion- fact <- (activate-orbi ter- cabin-o2 -pres sure-anomaly-rule) 

(AnalogFd (fdName "V61P2511A1 *) (value ?V6i?2SilAl_val) > 

(AnalogFd (fdName "V61P2513A1 ■ } (value ?V61P2513Al_val) ) 

(AnalogFd (fdName ■V61P251SA1") (value ?V61P2515AlIval) ) 

(test 

(or 

(> (abs (- ?V61P2511Al_val ?V61P2513AI_val )> 0.15 ) 

(> (abs (- ?V61P25i3Al_val ?VSl?2S15Al_val )) 0.1S > 

(> (abs (- ?VSl?2SUAl_val ?V6i?25i SAl.val >) 0.15 } 

(> (abs (- ?V61P2SUAl_val 3.1) > 0.3) 

(> (abs (- ?V61?2513Al_vai 3.1)) 0.3) 

(> (abs (— ?V6i?2S!5Al_val 3.1)) 0.3) 

> 


(retract ?activation-fact) 

(assert (orbi ter-cabin-o2-pressur e-anomaly-rule-reactivati on-act ivate) ) 
(notifyActionHandler 
(create? 

"http : / /xb70 . ksc . nasa.gov/ECL/ECL_Home/Launch . html " 

"http: //xb70 .ksc . nasa . gov/ECL/ECL_Home/Cabin_Leak . html " 

) 

(get -member LccmaCoior message_violation) 

(create? V61P2401A1 V61P2405A1 V61T2552A1) 


For this rule, three analog measurements, V61P251 1A1, 
V61P2513A1, and V61P2515A1, are monitored. The ab- 
solute value of the difference among pairs of these analog 
measurements must not exceed a given quantity. If anyone 


of them is exceeded, the rule will fire indicating an anomaly 
in the cabin oxygen pressure. Once fired, the right hand 
side of the rule executes. The notifyActionHandler 
call has three arguments. The first one contains two trou- 
bleshooting web page links that are made available to the 
NASA engineer. The second argument specifies the color 
of the message, a violation in this case. Finally, the third ar- 
gument species the three measurements that may be plotted 
to investigate the anomaly further. 

4. Future Exploration Agents 

As indicated in the national Vision for Space Exploration 
[18], an increased human and robotic presence will be cul- 
tivated in space, on lunar and Martian surfaces, and other 
destinations. Spaceports will now span from the Earth to 
the moon and beyond. A new set of challenges is presented 
by this Exploration Vision. In particular, the need for auton- 
omy significantly increases as people and payloads are sent 
greater distances from Earth. 

Agents for these future applications will demand much 
higher degrees of autonomy than today’s Shuttle agents. 
Few or no human experts will reside at remote lunar or Mar- 
tian sites to correct problems in a timely manner. More au- 
tomation will be required along with advanced diagnostics 
and prognostics. This requires higher levels of reasoning. 

Today on Earth, system and hardware engineers and 
technicians leverage multiple skills when monitoring, di- 
agnosing, and prognosticating problems in Shuttle ground 
support equipment. For the Exploration Vision, the need for 
extending these skills to support other vehicles at remote 
locations from the Earth to Mars becomes essential. These 
skills include being rational, collaborative, goal driven, and 
the ability to reason over time and uncertainty. The agent 
discussed earlier in the paper, LCCMA, is capable of shal- 
lowing reasoning of short inference chains within the Shut- 
tle domain. However, this existing agent can be endowed 
with higher levels of rationality enabling a deeper reason- 
ing. We are investigating how to mature LCCMA into a 




Spaceport Exploration Agent (SEA) in support of the Ex- 
ploration Vision. 

SEAs will need to communicate and collaborate along 
multiple and lengthy logistics chains. This does not simply 
include agents monitoring pre-flight checkout of vehicles at 
a terrestrial spaceport (e.g. LCCMA monitoring Shuttle ac- 
tivities). Rather, SEAs will reside in multiple locations at 
great distances. Logistics, scheduling, and planning are just 
some of the activities that these agents will manage. 

Within this virtual collaborative management chain, 
SEAs will be inundated with massive amounts of data that 
must be sorted and processed. It becomes necessary for 
them to revise their sets of beliefs as new data arrives. It is 
simply not enough to revise singular data points within an 
agent’s working memory and to have an agent blindly re- 
act to those changes. Rather, an agent must possess the abil- 
ity to revise previously concluded assertions based on what 
may be now stale data. This activity is called truth main- 
tenance [4, 10], also known as belief revision, and is 
particularly important when deep reasoning of long in- 
ferences is necessary. An assumption based truth main- 
tenance system (ATMS) can reason over many contexts 
simultaneously. By capturing, maintaining, and deploy- 
ing spaceport expertise within ATMS-enabled SEAs, the 
costs and manpower required to meet the Exploration Vi- 
sion are reduced while safety, reliability, and availability 
are increased. 

4.1. Benefits of Endowing Spaceport Exploration 
Agents with Belief Revision 

SEAs enabled with belief revision will provide the fol- 
lowing: 

• SEAs will continuously monitor spaceport telemetry 
streams for expected and anomalous conditions during 
operations and launch countdowns. SEAs wll analyze 
data from networks of sensors and draw inferences 
over time to deduce further action. Results are pro- 
vided to humans, agents, and other subsystems which 
may compose an integrated health management func- 
tion. 

• SEAs provide an automated explanation generation fa- 
cility and diagnostic capabilities. The inferences and 
facts that lead to a conclusion will be available to the 
human expert and other agents for further processing. 

• SEAs provide prognostics to predict where and when 
failures may occur in support equipment and what if 
scenarios to assess chains of events. 

• If a human expert leaves the program or moves onto 
other opportunities, SEAs remain and can virtually 
mentor the human replacement leveraging its knowl- 
edge base. 


4.2. Types of Questions to be Answered 

SEAs will be able to answer the following types of ques- 
tions: 

• Is there one or more faults in the support equipment? 

• Where is the fault most likely located? 

• What combination of data and events lead up to a fault 
(i.e. explanation generation)? 

• If a fault remains, what are its effects both locally and 
systemically, now and in the future. 

• What other systems and personnel need to be notified 
of the fault including both internal and external clients 
(e.g. command/control system, hardware subsystems, 
integrated health management, logistics, business sys- 
tems, etc.)? 

• What actions need to be taken by the system to address 
the fault from both a hardware and personnel perspec- 
tive? 

• Did the fault stress other previously healthy equipment 
that now needs to be repaired or replaced? 

4.3. Extending LCCMA with Truth Maintenance 

As indicated earlier, LCCMA uses Jess as its inference 
engine. Jess implements a lightweight version of truth main- 
tenance that is much simpler than a full blown ATMS. Jess 
uses a logical keyword that keeps track of the ’’here and 
now” for specified premises. Other rule based systems, such 
as Clips and Lisa [24], implement a similar level of truth 
maintenance. 

Premises on the left hand side of a rule can be tied to 
assertions of facts on the right hand side via the logical 
keyword. A dependency is created between the facts of the 
premise and the fact of the conclusion. After the rule fires 
and the consequent’s fact(s) is asserted, if the premise ever 
becomes false, the consequent’s facts will be automatically 
retracted. In contrast to Jess’ version of truth maintenance, 
an ATMS dependency network offers a full history of de- 
pendencies using an efficient labeling algorithm. It offers a 
history of everything that has happened as opposed to just 
the “here and now” as provided by Jess’ textitlogical key- 
word. Dependency tracking and proof histories have been 
researched [4, 10, 8] and implemented in other rule based 
expert system shells such as MIKE [7]. 

4.4. ATMS Background 

Using de Kleer’s model [4, 5, 6], an ATMS is com- 
posed of a set of nodes, ni, . . . , n n , where each node 
is a propositional variable. A proposition represents either a 
premise, contradiction, or assumption. A premise is a node 




Figure 5. Justification Class Diagram 


that is always true. A contradiction is a node that is al- 
ways false. An assumption is a node whose values may be 
changed by the inference engine during rule firings. The in- 
ference engine incrementally transmits these propositions 
(i.e. nodes) to the ATMS. 

When the inference engine fires a rule that results in a 
new or modified fact, a justification is transmitted to the 
ATMS. As shown in Figure 5, a justification is a tuple con- 
sisting of the rule’s antecedent and consequent forming the 
inference. Suggesting an ”if-then” type of implication, a 
justification may only contain positive literals and be rep- 
resented as a horn clause. 

From Figure 6, an ATMS node has a datum, justifica- 
tion, and label associated with it. The datum represents a 
rule or fact within the inference engine as indicated in Fig- 
ure 7. The justification is composed of an antecedent, con- 
sequent, and informant. The antecedent represents facts on 
the left hand side of the rule that caused the rule’s premises 
to be true and resulted in an activation and firing. The con- 
sequent represents facts that were asserted on the right hand 
side of the rule upon firing. The informant describes the type 
of deduction and is never used in any ATMS computations. 
It may be supplied to the inference engine to provide tex- 
tual cues for explanation generation. 

4.4.1. Interfacing an ATMS to the Jess Rule Engine In- 
terfacing an ATMS to a production rule system has been 
previously investigated by Morgue and Chehire [17]. In 
their study, two levels of coupling were described with re- 
spect to the match-select-act cycle of an inference engine. 
When an ATMS is loosely coupled with an inference en- 
gine, the select and act steps are modified to enable inte- 
gration. This is a simple form of interaction between the 
ATMS and inference engine and is more prone to becom- 
ing intractable than a tight coupling approach. In tight cou- 


Datum 



Figure 7. Datum Class Diagram 


pling, the match step is modified. This requires changes to 
the Rete algorithm of the inference engine. 

To extend LCCMA with full dependency tracking via 
an ATMS, Jess offers sophisticated event handling that will 
readily enable communication between the Jess inference 
engine and the ATMS. Event handlers are supplied and in- 
voked when, for example, a fact is asserted, retracted, or 
modified. In conjunction with an ATMS facility, these han- 
dlers could build and maintain a complete history and de- 
pendency network. 

Inspired from the Lisp interface definition of Forbus and 
de Kleer [10], Figure 8 shows the Atms class with anal- 
ogous Java method signatures for an Atms interface def- 
inition supporting the Jess inference engine. The Atms 
class realizes the Atms Interface and thus implements 
the interface’s methods. The InferenceEngine class 
depends upon the Atms Interface. The createNode 
and justifyNode methods of the Atms class are not 
publicly accessible as indicated by the leading minus signs 
by the method names. They are called after the Atms ob- 
ject receives a message from the inference engine indicat- 
ing that a new fact was created or a fact was modified by a 













Figure 8. ATMS Class Diagram 
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Figure 9. ATMS Sequence Diagram 


rule firing resulting in an ACTIVATION event. See the se- 
quence diagram in Figure 9. 

5. Conclusion and Future Work 

An agent that monitors Space Shuttle ground telemetry 
data was presented. LCCMA provides an increased insight 
for NASA system and hardware engineers. LCCMA has 
successfully detected launch commit criteria warnings and 
violations on a simulated playback data stream. We are in- 
vestigating extending this agent with truth maintenance ca- 
pabilities to support advanced diagnostics and prognostics. 

Future work includes incorporating probabilities of oc- 
currence of faults within support equipment. In terms of the 
ATMS, this translates into the probabilities of a fact being 
derivable and the context within which it would appear. Pre- 
vious research has shown the utility of Bayesian networks 


and their applicability for constructing probability distribu- 
tions from an ATMS [20]. 

Brachman and Levesque [2] propose description logics 
to implement a production system, act as the working mem- 
ory, or provide some other service to such a system. In this 
paper, the subsumptive power of description logics might be 
leveraged by the label update algorithms of the truth main- 
tenance system. Further, both agent applications and Jess it- 
self are implemented in Java, an object oriented language. 
Description logic taxonomies might be constructed to natu- 
rally mirror the object oriented models of the agents. 
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